…ta. (#23733)

# Objective

- A possible step towards #10981.
- Followup to #22520.
- We accidentally have two implementations of the same thing! We created
a way to collect schedule data in `bevy_dev_tools` and in `bevy_remote`.
`ScheduleData` is a more complete implementation of collecting schedule
data, and is less tied to the internals of BRP (e.g., it supports
serializing to disk instead of only through the BRP API), so we switch
to that.

## Solution

- Replace the implementation of `schedule.graph` with the `ScheduleData`
API.

A disadvantage is that we now need to wait for the schedules to be
initialized before we can read them. Since users have to connect with
BRP though, it is almost certain that the schedules will be initialized
by the time they request the schedules. This may not be true of
schedules like state transitions though - since these only run rarely.
In a future PR, we can build the schedules on-demand instead.

## Testing

- Updated the test for this.
- Ran the same test as #23452
    - Terminal 1: `cargo r --example server --features=bevy_remote`
- Terminal 2: `curl
-d'{"jsonrpc":"2.0","method":"schedule.graph","id":1,"params":{"schedule_label":"First"}}'
-X POST -H "Accept: applcation/json" -H "Content-Type: application/json"
http://127.0.0.1:15702`
    - It dumped out a whole load of JSON that looked expected!
- I don't have a visualization of the schedule data yet, so I can't
validate that it's correct, but there's no reason to believe its wrong
given the existing `ScheduleData` tests.

…ta. (bevyengine#23733)

# Objective

- A possible step towards bevyengine#10981.
- Followup to bevyengine#22520.
- We accidentally have two implementations of the same thing! We created
a way to collect schedule data in `bevy_dev_tools` and in `bevy_remote`.
`ScheduleData` is a more complete implementation of collecting schedule
data, and is less tied to the internals of BRP (e.g., it supports
serializing to disk instead of only through the BRP API), so we switch
to that.

## Solution

- Replace the implementation of `schedule.graph` with the `ScheduleData`
API.

A disadvantage is that we now need to wait for the schedules to be
initialized before we can read them. Since users have to connect with
BRP though, it is almost certain that the schedules will be initialized
by the time they request the schedules. This may not be true of
schedules like state transitions though - since these only run rarely.
In a future PR, we can build the schedules on-demand instead.

## Testing

- Updated the test for this.
- Ran the same test as bevyengine#23452
    - Terminal 1: `cargo r --example server --features=bevy_remote`
- Terminal 2: `curl
-d'{"jsonrpc":"2.0","method":"schedule.graph","id":1,"params":{"schedule_label":"First"}}'
-X POST -H "Accept: applcation/json" -H "Content-Type: application/json"
http://127.0.0.1:15702`
    - It dumped out a whole load of JSON that looked expected!
- I don't have a visualization of the schedule data yet, so I can't
validate that it's correct, but there's no reason to believe its wrong
given the existing `ScheduleData` tests.